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PBEFACE 

This  thesis  discusses  the  design  of  an  interactive  student 
ccmpiler  systei  called  HITS,  an  acrcnym  for  "White's  Interactive 
Timesharing  System."  The  HITS  system  currently  contains  two 
editors,  twc  filing  lessons,  and  two  compilers.  Work  is  in 
progress  cr  creating  additional  editors  and  compilers,  in  order 
tc  tetter  meet  the  needs  of  its  users.  These  compilers  have 
been  inplcaerted  or  the  Plate  IV  computer  system,  and  are  being 
used  by  students.  Included  in  this  thesis  is  a  description  of 
the  Flato  IV  system  and  hew  it  affected  the  development  of  HITS. 


Chapter  1 


Introduction 


The  Plate  IV  system  [ Alpert, 1970 ]  is  a  computer  based 
educational  system  developed  at  the  University  of  Illinois. 
Various  user  groups  at  Plate  have  been  interested  in  designing 
or  using  interactive  compilers  for  student  programs.  Two  such 
systems  of  compilers  have  been  implemented  on  Plate.  This 
t.h3sis  discusses  the  design  considerations  that  went  into  the 
i nplementat icn  of  cne  of  these  compiler  systems  and  the  results 
of  that  design.  The  compiler  system  described  here  is  called 
WITS,  an  acrcnym  for  "White's  Interactive  Timesharing  System." 
Throughout  this  thesis,  occasional  comparisons  are  made  to  the 
other  compiler  system,  CAPS  [ Wilccx, 1976  ],  which  has  been 
implemented  by  the  Computet  Science  Department  at  the  University 
of  Illinois. 


In  order  to  give  some  basis  for  the  discussion  of  the 
design  chesen  fcr  WITS,  the  first  two  chapters  describe  the 
users  cf  the  WHS  compilers  and  the  computer  system  on  which 
WITS  was  implemented.  Chapter  4  describes  the  goals  the  WITS 
designers  had  in  implementing  their  system.  Chapters  5  and  6 
describe  HITS  as  it  currently  is,  and  how  it  became  that  way. 


Chapter  2 
Users  of  Interactive  Compilers  on  Plato 

Before  the  implementation  of  any  computer  programming 
system,  consideration  must  be  given  to  the  type  of  users  the 
system  will  have,  and  what  their  needs  are.  In  designing  WITS, 
several  user  groups  were  kept  in  mind,  in  an  attempt  to  make  the 
system  general  enough  to  be  used  by  many  groups.  The  user 
groups  the  author  has  had  experience  with  are  described  below, 
alonq  with  their  reeds  as  seen  by  the  compiler  designers. 

_2_-_l_. Educational  Psychology 

BASIC  [ Kemeny, 1 967  ]  is  a  simple  programming  language, 
primarily  intended  for  numerical  applications.  Because  of  its 
simplicity  and  its  acceptance  in  the  education  environment,  it 
was  chosen  as  the  first  language  to  be  implemented  on  Plato. 
The  compiler  das  written  for  Professor  Kenneth  Travers  of  the 
Secondary  Education  Department,  and  for  Axel  T.  Schreiner  of  the 
Mathematics  Department,  both  at  the  University  of  Illinois.  As 
understood  by  the  compiler  designers,  Dr.  Travers  was 
instructing  future  teachers  in  hew  to  teach  BASIC.  Since  his 
students  would  later,  in  most  cases,  be  using  small  interactive 
systems  utilizing  Teletypes  for  communication.  Dr.  Travers 
wanted  the  user  interface  of  the  BASIC  system  we  built  on  Plato 
to  resemble  such  a  system.   In  particular,  his  reguirements  were 


as  follows: 


1)  User  interface  similar  to  standard  interactive  system, 
A)  Teletype  like  appearance. 

E)  Clear  distinction  between  editing  and  compiling. 
C)  Ccnmand  directives,  rather  than  user  choice  pag€. 

2)  Frovide    simple    program    preparation   facilities. 
A)    Permanent    program   storage    space   for    10    users. 
E)    Line-criented    text  editor. 

3)  Compile  and  execute  small  BASIC  programs. 


Unfortunately  for  the  Education  Department's  students,  the 
Plato  system  was  still  experimental  at  that  time,  and  rather 
unstable.  Additionally,  these  students  were  the  first  to  use 
the  forerunner  cf  the  WITS  system,  and  they  found  many  bugs  in 
the  editcr,  filing  system,  and  BASIC  interpreter.  To  their 
credit,  they  stuck  with  the  system  for  two  or  three  semesters 
while  the  Plate  system  was  stabilizing  and  we  were  fixing 
problems  in  our  lessons. 

2^2^ Computer  Calculus 


Cne  of  the  cc-authors  of  that  first  system,  and  the  real 
desiqner  cf  cur  BASIC  compiler.  Axel  T.  Schreiner,  was  at  that 
time  designing  "Computer  Calculus"  [ Schreiner, 1972  ],  a 
laboratory  course  supplementing  regular  Calculus  instruction  at 
th<=  University  of  Illinois.  His  students  were  writing  small 
numerical  analysis  and  graphical  programs  using  CAIL/360-OS 
EASIC  [IBH]  en  FIOBTS  [Gear, 1969],  a  local  interactive 
timesharing  system.  For  the  purpese  of  Computer  Calculus,  the 
Mathematics  Department  had  set  up  a  laboratory  room  connected  to 


the  IBM/36C-75  operated  by  the  Computing  Services  Office  at  the 
University  of  Illinois.  This  laboratory  had  16  teletypes  for 
program  preparation  and  alphanumeric  input  and  output,  along 
with  a  saall  Hewlett-Packard  flat-bdd  plotter,  connected  to  one 
of  the  teletypes,  fcr  graphical  output. 

Mr.  Schreiner  became  interested  in  using  Plato  for  the 
qraphics  pcrtion  cf  the  Computer  Calculus  classes,  and  wrote 
seme  instructional  lessens  on  Plato  for  this.  Later  he  expanded 
his  interests  to  include  using  Plate  for  a  section  of  his 
students  tc  run  EASIC  programs.  Fcr  Computer  Calculus  students 
tc  use  Plate  for  EASIC,  they  would  need  essentially  the  same 
facilities  as  Professor  Travers  needed,  but  for  20  students 
simultaneously,  not  10. 

Tc  meet  the  goals  of  these  twe  user  groups.  Educational 
Psychology  and  Computer  Calculus,  the  user  interface  of  the 
first  EASIC  system  implemented  on  Plate  looked  very  much  like 
PICRTS,  tc  the  extent  that  some  of  the  editing  commands  were 
identical  tc  those  en  PLOFTS.  This  system  was  used  by  Education 
and  Calculus  students  until  a  more  advanced  system,  called  HITS, 
was  inplemented. 

2_.  3.. University  High  Schocl 

The  heart  cf  the  HITS  system  was  written  in  the  fall  of 
1973,  using  seme  new  features  of  the  Flato  system,  and  was  first 
used  the  following  spring.  HITS  allowed  for  the  connection  of 
any  number  of  user  groups  to  cne  filing  system,   all   using   the 


same  editor  and  compiler.  The  first  new  group  of  users  was  from 
University  Hiqh  School,  which  already  had  access  to  Plato,  and 
whose  instructors  were  interested  in  teaching  their  students  to 
program. 

The  "Dnihi"  students  had  no  previous  experience  with  other 
computer  systems,  and  in  many  cases,  WITS  was  their  first 
encounter  with  Plato.  These  students,  rather  than  using 
programming  to  learn  another  subject,  as  were  the  Calculus 
students,  were  learning  about  computers,  computer  systems,  and 
programming.  As  such,  the  HITS  system  was  one  of  the  things 
they  were  learning  about,  rather  than  being  just  a  tool  in  the 
study  cf  something  else. 

The  basic  reguirements  for  the  University  High  School 
students  were  slightly  different  from  those  of  the  other  user 
groups  previously  described.  What  they  needed  HITS  to  provide 
are  described  below: 

1)  Frovide  a  programming  system  at  small  additional 
ccst  to  the  school. 

2)  Ee  simple  enough  to  allow  seme  guick  achievements 
for  students,  powerful  enough  to  hold  their  interest 
for  a  semester  or  two. 

3)  Ee  simple  enough  to  explore  by  trial  and  error,  safe 
enough  so  students  can  not  accidently  hurt  anything. 

4)  Provide  filing  space  for  35  students. 

The  original  HITS  system  filled  all  these  needs,  so  the 
University  High  School  students  started  using  it.  As  HITS  has 
expanded   to   include   a  Fortran  compiler  and  another  editor  and 


filing  system,  Unihi  students  have  continued  to  utilize  all   the 
capabilities  cf  the  HITS  system. 

2..J4_. C  S  1 0  5 

The  Computer  Science  Department  at  the  University  of 
Illinois  has  been  wcrking  for  a  few  years  to  automate  their 
introductory  programming  ccurses  [ Nievergelt, 1974 ].  To  do  this, 
members  of  the  department  have  written  many  instructional 
lessens  on  Plato,  and  have  implemented  interactive  diagnostic 
compilers  for  subsets  of  several  programming  languages 
[ Hilccx,1 S76 }.  Of  particular  interest  is  the  CS105  programming 
course,  with  about  1000  students  each  semester.  The  HITS 
desiqners  have  tried  to  expand  their  compiler  systei  to  support 
this  group,  but  due  to  the  large  number  of  students,  this 
attempt  has  been  only  partially  successful. 

CS105  is  an  introductory  programming  course  for  business 
students.  In  many  cases,  this  will  be  their  only  programming 
course,  which  they  take  because  it  is  required  of  them.  Such  a 
group  is,  en  the  whele,  only  interested  in  getting  their  machine 
probleus  dene  with  the  least  amcunt  of  effort.  They  are  not 
interested  in  learning  hew  editors  or  filing  systems  work 
(unless  that  is  assigned  to  them) ,  and  they  are  very  intolerant 
when  they  can  not  get  the  system  to  wcrk. 

Since  there  are  so  many  cf  these  students,  they  are 
scheduled  rather  tightly,  and  are  unlikely  to  come  in  on  their 
own  time,  unless  it  is  to  finish  a  late  programming   assignment. 


Due  tc  the  large  number  of  students,  a  different  organization  of 
resources  nay  he  required  in  HITS  to  handle  them  all.  Below  are 
listed  the  major  requirements  to  use  IITS  for  Introductory 
Computer  Science  Courses  at  the  University  of  Illinois: 

1)  Provide  Fortran  and/cr  PL/1  compilers. 

2)  Support  40  simultaneous  users. 

3)  Frovide  filinq  space  for  1000  students. 

4)  Use  a  minimum  of  costly  system  resources. 

5)  Provide  self-explanatory  editors  and  filinq  systems. 

Expected  use  of  HITS  in  the  near  future  by  the  CS 
department  appears  rather  minimal  at  this  time.  This  is  due  to 
the  department  havinq  its  own  compilers  on  Plato,  and  to  the 
availability  cf  batch  compilers  on  CSC»s  IBM  System  360/75.  One 
way  HITS  miqht  be  used  is  as  an  intermediate  step  between  their 
Plate  Compilers  and  the  360.  The  students  could  learn  the  basic 
features  cf  a  prcqramminq  lanquaqe  usinq  the  departments 
diaqnestic  compilers  on  Plato,  and  could  then  move  to  HITS  for 
writinq  lenqer  prcqrams,  and  later  move  to  the  360  to  learn 
about  a  batch  oriented  system,  printed  output,  file  I/O,  and 
still  larqer  proqrams. 

2_.  5. Visiters 

In  addition  tc  servinq  the  orqanized  qroups  described 
ahove,  the  HI1S  desiqners  have  encouraqed  people  to  set  up  Plato 
records  so  students  miqht  "visit"  the  HITS  system.   Several  such 
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visiter  records  have  been  created  for  students  to  practice 
proqua  a  irinq  on  their  own.  In  some  cases,  these  students  have 
even  teen  provided  with  disk  space  for  storing  their  programs 
between  sessiens.  If  they  do  have  such  space,  it  is  shared 
between  all  users  of  their  Plato  signon.  For  HITS  to  support 
such  visiters,  the  following  are  needed: 


1)  Visitors  may  write  and  run  programs  even  if  they  are 
not  allocated  file  space. 

2)  They  shculd  not  be  able  to  interfere  with  regular  users 
cf  HITS. 

3)  Help  paqes  shculd  be  provided  to  answer  their  guestions 
without  Deeding  an  instructional  book  or  teacher. 

4)  WITS  should  wcrk  reasonably  well  with  a  single  user. 


2..  6_. Future  Users 

In  the  next  few  years  it  is  expected  that  the  Plato  system 
will  expand  to  include  several  computers  at  different 
universities.  The  designers  cf  HITS  are  trying  to  make  their 
system  transportable  to  other  Plato  systems.  To  do  so,  they 
expect  the  following: 

1)  Eiverse  user  needs,  as  above. 

2)  Visitors  may  be  familiar  with  the  Plato  editor,  and 
want  a  similar  editor  fcr  HITS. 

3)  Resource  use  ty  HITS  may  be  a  critical  factor. 

4)  HITS  data  structures  should  te  stable,  even  if  the 
host  system  is  occasionally  unstable,  since  the  HITS 
designers  will  not  be  around  to  correct  problems. 


Chapter  3 
The  Elato  IV  System 

When  designing  a  compiler  system  for  a  particular 
environment,  it  is  often  just  as  important  to  understand  what 
that  environment  can  support  as  it  is  to  understand  what  the 
users  will  need.  In  early  1973  it  was  thought,  fcr  one  reason 
or  another,  that  Elate  couldn't  support  student  compilers. 
Claims  were  made  that  Tutor,  Plate's  programming  language,  was 
net  powerful  enough  fcr  a  compiler;  Tutor's  data  areas  and 
structures  were  too  small  cr  too  simple;  or  Plato's  CPU  capacity 
was  insufficient.  That  was  before  Axel  Schriner  designed,  and 
he  and  the  author  iiplemented,  their  first  BASIC  system.  They 
showed  that  Plate  could  support  a  compiler  system,  if  that 
system  were  designed  and  inplemented  carefully,  and  if  the  users 
were  running  "reasonable"  programs.  Since  the  capabilities  of 
Plato  strcngly  affected  the  design  of  WITS,  the  next  few 
sections  describe  Plato,  sc  that  later  discussions  of  WITS  will 
be  mere  firirly  based. 

Ihe  goal  in  the  design  of  Plato  was  to  provide  high  guality 
educaticn  at  low  ccst  [ Bitzer ,  1973  ].  The  method  of  achieving 
this  goal  was  to  use  a  powerful  computer  to  enable  the  creation 
of  quality  instructional  materials,  and  to  keep  the  cost  per 
student  low  by  running  hundreds  of  students.  One  of  the 
important   characteristics   of   quality  CAI  is  fast  and  flexible 
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feedback  to  the  student,  giving  better  reinforcement  in 
learning.  Hew  Plato  provides  fast  response  to  student  input  is 
described  in  the  next  two  sections.  One  section  is  concerned 
with  the  central  computer,  the  other  section  outlines  the 
cemmun icatiens  system. 

3_j_K Central  Computer  Architecture 

The  computer  on  which  Plato  runs  is  one  of  Control  Data 
Corporation's  60C0  series.  Specifically  at  the  Urbana  Plato 
system,  a  Cyber  73  is  used.  The  Cyber  73  has  two  Central 
Processing  Units  (CPUs) ,  and  ten  Peripheral  Processing  Units 
(PPUs) .  The  FPUs  ccntrcl  communications  between  the  computer 
and  ether  devices,  such  as  printers,  tape  drives,  and  the  disk 
system.  In  addition,  the  PPUs  handle  the  main  part  of  system 
job  scheduling,  telling  the  CPUs  what  to  do.  The  CPUs  do  most 
of  the  work  in  running  prcgrams,  including  the  execution  of 
Plato  lessens.  Mere  on  the  design  of  the  central  computer  may 
be  found  in  I"  Thorton,  1970  ],  though  he  basically  discusses  the 
CEC  6€CC. 

Many  standard  interactive  computer  systeis  employ  something 
known  as  "swapping"  in  their  operation.  Swapping  involves 
keeping  the  informaticn  needed  for  all  users  on  soie  secondary 
memory  device,  generally  slower  and  cheaper  than  main  memory, 
and  transfering  one  user's  information  into  main  memory  whenever 
he  needs  to  execute.  This  is  mainly  an  economic  feature, 
allowing  the  computer  to  get  by  with  less  nain  memory  than  would 
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be  needed  if  all  active  users  were  kept  there  all  the  time.  The 
transfer  speed  between  the  secondary  lemory  and  main  memory  is 
often  an  important  factor  in  how  well,  or  how  many  users,  the 
system  can  run,  both  of  which  are  important  aspects  of  the  Plato 

system . 


In  order  to  provide  good  response  time  for  many  users, 
Plato  uses  Control  Data  Corporation's  Extended  Core  Storage 
(ECS)  for  its  secondary  memory  storage.  The  transfer  rate 
between  ECS  and  Plato's  main  memory  (called  Central  Memory  or 
CK)  is  6CC  million  bits  per  second.  This  high  transfer  rate 
allows  Fiatc  to  swap  its  users  in  and  out  of  CM  very  guickly. 
However,  in  addition  to  Plato  using  ECS  to  perform  a  fast  swap 
ot  users,  Flatc's  programming  language  allows  users  to  directly 
access  data  areas  in  ECS.  Thus,  ECS  goes  beyond  -just  being  a 
transparent  system  implementation  feature,  invisible  to  the 
users;  it  affects  the  whole  design  of  data  manipulation 
programs,  including  those  in  the  WITS  system.  The  data  areas  in 
ECS  that  a  lesson  may  reference  are  described  in  Section  3.5. 

Many  computer  systems  use  disk  packs  for  their  swapping 
medium.  Due  to  its  much  longer  access  time  and  lower  transfer 
rate,  disk  packs  are  used  by  Plato  only  for  the  permanent 
storage  of  icf reguently  accessed  data.  Among  the  types  of 
informaticr  Plato  stores  on  disk  are  the  permanent  records  for 
all  users,  the  scurce  code  for  lessons,  files  for  collection  of 
data  en  active  students,  and  files  for  normal  lessons  to  store 
data   in.    At   the   start  of  a  session,  a  user's  information  is 
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read  from  disk  into  ECS,  and  it  is  stored  back  on  disk  when  he 
signs  off.  Ey  storing  a  user's  intonation  in  ECS  during  a 
session,  the  number  of  disk  accesses  required  to  run  a  student 
is  reduced,  and  the  time  needed  to  access  a  user's  information 
is  shortened.  A  similar  strategy  is  employed  with  most  other 
data  references.  For  example,  when  editing  the  source  code  of 
Plato  lessens,  the  text  is  brought  into  ECS  in  blocks  of  a  few 
hundred  words,  frcm  where  it  is  edited  and  later  returned  to 
disk. 

3.-2_. Terminal  Communications 

In  providing  fast  response  to  user  input,  two  things  are 
important,  the  time  reguired  to  set  up  a  user  for  processing  and 
the  ccumunicaticn  time  tc  the  terminal.  The  swapping  of  users 
was  briefly  discussed  in  the  preceding  section,  while  this 
section  describes  the  communication  to  the  terminal.  This 
communication  did  not,  however,  affect  the  design  of  HITS  as 
much  as  did  Plato's  architecture,  so  it  is  described  even  more 
briefly.  More  complete  information  is  available  from 
rstifle,1572]. 

Each  Plate  teisinal  is  designed  to  connect  to  a  voice  grade 
phone  line  (1260  baud),  which  is  in  turn  connected  to  a  Plato 
Site  Controller.  Each  site  controller  handles  the  input  and 
output  of  32  terminals.  Input  to  the  computer  from  each  site 
controller  is  provided  by  a  phone  line  to  the  Network  Interface 
Unit   or  NID  [ Tucker,  1971  ].   Cutput  from  the  central  computer  is 
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passed  to  the  NIU,  where  it  is  formatted  into  a  video  signal. 
Output  to  1008  terminals  reaches  over  a  video  cable  from  the  NIU 
to  all  site  controllers,  each  of  which  picks  off  the  output 
meant  for  their  own  32  terminals. 

At  the  central  computer  site,  input  and  output  through  a 
channel  tc  the  NIO  is  directed  by  a  program  running  on  a  PPU. 
This  FEU  program  stores  key  input  from  the  terminals  in  ECS  and 
tells  a  CEU  program  where  to  find  the  key  input.  The  PPU 
prcgrair  is  alsc  responsible  for  picking  up  the  output  waiting  to 
qo  to  the  terninals  and  sending  it  to  the  NIU.  The  Plato 
interpreter  pells  the  input  tables  looking  for  keys  every  50 
milliseconds,  giving  each  terminal  with  a  key  a  timeslice  of 
computation.  In  addition  to  keys  from  the  NIU,  Plato  may 
generate  pseudo-keys  to  indicate  that  a  terminal  needs  to 
continue  seme  computation  that  was  previously  interrupted. 

3.3.   Student  Terairal 


The  Plate  IV  student  terminal  is  designed  tc  provide 
features  desireable  for  many  teaching  applications.  The  basic 
terminal  includes  a  graphic  display  panel  for  output  and  a 
keyset  for  input.  Cptional  accessories  include  a  slide  selector 
for  displaying  slides  on  the  panel,  an  audio  device  supporting 
recorded  messages,  and  a  touch  panel  for  providing  touch 
sensitive  irput.  Jacks  are  provided  on  the  back  of  the  terminal 
for  adding  external  devices.  The  bandwidth  to  the  terminal  is 
126C   baud,   higher   than  that  used  at  most  timesharing  systems. 
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The  terminal  features  that  affected  the  development  of  WITS  are 
descrited  below.  A  more  complete  terminal  description  may  be 
obtained  frcm  [ Stifle,  1973  ]. 

The  display  device  in  the  terminal  is  an  8  1/2  inch  square 
plasma  pannel,  containing  a  grid  of  512  by  512  dots,  each  of 
which  may  be  illuminated  independently.  The  plasma  panel 
display  needs  no  refreshing  to  held  a  display,  as  does  a  CRT, 
and  its  orange  dots  on  a  black  background  provide  high  contrast, 
flicker  free  cutput.  The  display  may  be  referenced  in  "fine 
grid"  rotation,  using  (x#y)  pairs  in  the  range  from  (0,0)  to 
(511,511)  to  indicate  points.  Alternately,  the  panel  may  be 
referenced  in  "coarse  grid"  notation,  as  32  lines  of  64 
characters  each.  Each  character  position  is  16  dots  high  by  8 
dots  wide. 

Since  student  programs  in  the  WITS  system  may  be  longer 
than  32  lines,  some  method  is  reguired  to  show  only  part  of  a 
student's  program  at  once.  In  a  "teletype"  editor  for  BASIC 
programs,  this  is  dene  by  writing  lines  down  the  screen  and  then 
wrapping  arcund  tc  the  top  of  the  screen.  In  a  "cursor"  editor, 
the  student's  workspace  is  divided  into  three  "pages"  of  30 
lines  each,  with  the  student  being  able  to  move  from  one  page  to 
another.  In  a  "tutor"  editor,  so  called  because  of  its 
resemblance  to  the  standard  Plato  source  editor,  the  student 
moves  a  "frafe"  arcund  within  his  program,  and  all  lines  within 
the  frame  are  displayed  on  his  screen. 
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Since  the  display  width  is  only  64  characters,  the  maximum 
lenqth  cf  a  line  cf  text  in  WITS  was  chosen  as  60  characters,  to 
leave  space  fcr  displaying  line  numbers-  Continuation  lines  did 
not  appear  to  be  necessary,  but  were  implemented  in  the  Fortran 
compiler  as  an  extra  feature.  Output  from  a  running  program  is 
-1--  cn   "^racters,  a  significant  departure  from  the 
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using  several  characters  from  the  alternate  character  set,  and 
tc  display  the  picture  very  rapidly,  at  character  display  speed, 
rather   than   at   line  drawing  speed.   A  good  example  of  this  is 
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The  terminal  features  that  affected  the  development  of  HITS  are 
described  below.  A  more  complete  terminal  description  may  be 
obtained  frcm  [ Stifle,  1973  ]. 

The  display  device  in  the  terminal  is  an  8  1/2  inch  square 
plasma   pannel,   containing   a   grid  of  512  by  512  dots,  each  of 
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another.  In  a  "tutor"  editor,  so  caliea  Because  oi  its 
resemblance  to  the  standard  Plato  source  editor,  the  student 
moves  a  "fraire"  arcund  within  his  program,  and  all  lines  within 
the  frame  are  displayed  on  his  screen. 
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Since  the  display  width  is  only  64  characters,  the  maximum 
length  cf  a  line  cf  text  in  WITS  was  chosen  as  60  characters,  to 
leave  space  for  displaying  line  numbers.  Continuation  lines  did 
not  appear  to  be  necessary,  but  were  implemented  in  the  Fortran 
compiler  as  an  extra  feature.  Output  from  a  running  program  is 
also  limited  to  60  characters,  a  significant  departure  from  the 
mere  ccnverticral  line  printer  width  cf  120  or  more  characters 
fcund  en  racst  systems. 


Alphanumeric  writing  on  the  plasma  panel  is  accomplished 
using  the  terminal's  character  generator.  This  generator 
implcys  four  "memories,"  in  which  are  stored  the  dot  patterns 
that  represent  characters.  Each  memory  contains  the 
representation  of  63  characters,  each  character  consisting  of  8 
times  16  dots.  The  terminal  can  take  from  the  character 
memories  the  8  by  16  bit  pattern  that  represents  a  character  and 
display  it  anywhere  on  the  screen.  Two  of  these  memories  are 
built  with  the  "standard"  characters,  i.e.,  the  representations 
of  the  126  characters  that  are  considered  to  be  the  most  useful. 
The  other  two  memories  may  be  loaded  under  program  control  with 
any  character  set  the  user  desires.  This  "alternate"  character 
set  has  many  uses.  Some  standard  uses  include  loading  a  few 
special  characters  needed  in  mathematics  lessons,  or  whole 
alphabets  needed  in  foreigr  language  lessons.  Another  very  nice 
way  to  use  the  alternate  character  set  is  to  design  pictures 
using  several  characters  from  the  alternate  character  set,  and 
tc  display  the  picture  very  rapidly,  at  character  display  speed, 
rather   than   at   line  drawing  speed.   A  good  example  of  this  is 
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the  Plato  IV  version  of  the  biology  lesson  "fly"  [ Hyatt, 1972  ], 
in  which  fruit  flys  with  various  genetic  traits  are  displayed 
using  combinations  of  alternate  characters. 

One  way  of  thinking  of  the  loadable  character  set  is  as  a 
way  of  changing  the  display  form  of  Plato  internal  character 
codes.  Conversely,  if  the  loadable  character  set  contains  a 
rearrangement  of  the  standard  character  set,  this  can  be  thought 
of  as  rearranging  the  internal  codes  used  to  store  characters. 
Standard  Plate  format  for  character  storage  is  a  Mixture  of  six, 
12,  and  18  tit  codes.  Opper  case  letters,  such  as  commonly  used 
by  programming  systems,  are  12  bit  codes  in  standard  Plato 
format.  The  lessens  in  the  HITS  system  use  the  alternate 
character  set  to  rearrange  the  internal  codes  of  characters,  so 
each  supported  character  can  be  stcred  in  a  six  bit  code.  This 
decreases  the  space  needed  to  store  a  program,  and  also, 
decreases  the  complexity  of  the  compilers  and  editors  in  the 
HITS  system. 

The  terminal  contains  a  vector  generator,  allowing  it  to 
draw  lines,  given  only  the  endpoints  of  each  line.  This  allowed 
the  incor pcration  of  some  plotting  features  in  the  implemented 
BASIC  language.  On  PLORTS,  one  flat  bed  plotter  was  shared 
between  all  students  of  each  Computer  Calculus  section.  On 
Plato,  graphic  plotting  was  available  at  each  student  terminal. 
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3_.4_. Software 

Plate  supports  but  one  language,  Tutor  [ Sherwood, 1 974  ],  for 
its  users.  Tutor  has  developed  under  the  direction  of  Paul 
J.  Tenczar,  head  cf  Plato's  system  software  staff,  as  a  command 
oriented,  second  generation  language.  It  is  much  more  powerful 
and  easy  to  use  in  teaching  applications  than  most  programming 
languages  ard  many  CAI  languages  [ Lower, 1 976  ].  In  non-teaching 
applications,  such  as  the  HITS  system.  Tutor  provides  as  much 
power  as  many  general  programming  languages,  though  it  is 
sometimes  awkward  in  such  situations.  To  use  Tutor  for 
non-teaching  applications  often  reguires  much  training  and 
practice,  after  which  it  may  still  te  difficult  to  use. 


A  Tutor  program  is  called  a  "lesson,"  and  consists  of  a  few 
hundred  to  a  few  thousand  lines  of  code.  Each  lessen  is  further 
divided  into  "units,"  each  containing  anywhere  from  one  to  a  few 
hundred  lines  of  code.  Program  seguencing  has  traditionally 
be^n  from  unit  to  unit,  with  each  unit  performing  a  specific 
function.  This  allows  easy  structuring  of  a  lessen  into 
functicnal  nodules. 


Each  Tutcr  command  may  reguire  many  machine  operations,  and 
for  the  Tutcr  compiler  to  generate  machine  code  for  each  command 
would  result  in  very  large  binaries  for  lessons.  To  reduce  the 
code  needed  in  each  lesson,  the  compiler  "condenses"  Tutor  code 
into  an  easily  interpretable  form  for  the  runtime  system  to 
interpret.  Tc  save  execution  time,  however,  the  compiler 
qenerates  machine   cede   for   expressions,   which   may   then   be 
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directly  executed  by  the  computer. 

Like  all  the  ether  information  needed  for  each  user, 
lessons  are  kept  in  ECS  and  swapped  into  CM  only  when  needed. 
The  organizaticn  of  a  Tutor  lesson  into  units  relates  itself 
very  well  with  Plato's  architecture.  Each  unit  is  a  self 
contained  part  cf  a  lesson,  and  gets  swapped  into  CM 
independently  of  the  rest  cf  the  lessen.  In  trying  to  write 
fast  Tutor  code,  one  remembers  that  there  is  seme  overhead  in 
bringing  units  into  CM,  and  that  it  may  be  faster  to  branch 
within  the  unit  than  to  load  another  unit  from  ECS. 

The  data  referenced  by  Tutor  lessens  is  kept  separate  from 
the  lesson  itself,  and  the  interpretable  code  within  the  lessen 
is  never  changed  during  execution.  Thus,  the  condensed  code  for 
all  lessens  is  automatically  reentrant  and  reuseable  as  far  as 
Plato  is  concerned.  This  allows  a  minor  speedup  by  not  having 
tc  write  units  tack  to  ECS  after  execution,  and  a  major  savings 
in  ECS  use  ty  allowing  any  number  of  users  to  share  the  ECS 
binary  cf  a  lessen. 

3.5.   Tutor  Data  Areas 

Previous  sections  have  mentioned  the  data  storage  resources 
the  Plato  system  has,  namely  CM,  ECS,  and  disk  space.  In  the 
distant  past,  normal  Tutor  lessons  could  only  access  data  in 
Central  Memory,  with  Plato  controlling  all  reading  and  writing 
of  ECS.  Since  then,  additional  commands  have  been  added  to 
Tutor   to   allow  lessens  tc  access  data  in  CM,  ECS,  and  en  disk. 
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Since  lessens  in  the  WITS  systea  use  all  three  of  these   storage 
areas,  their  characteristics  and  use  are  described  below. 

Each  user,  when  he  signs  onto  the  Plato  system,  is 
allocated  a  40C-500  word  area  of  ECS,  called  the  "student  bank." 
A  portion  of  this,  150  words  long,  is  called  "student 
variables,"  and  can  be  modified  explicitly  by  the  code  of 
whatever  lessen  the  user  is  currently  in.  The  rest  of  the 
student  back  is  used  by  Plato  to  store  status  information  needed 
during  a  session.  Much  of  the  student  bank,  including  the 
student  variables,  is  saved  en  disk  between  sessions,  often 
allowing  the  student  to  resume  a  lesson  at  a  later  session  at 
the  point  frcm  where  he  left  it  earlier. 

In  addition  to  student  variables,  a  Tutor  lesson  may 
request  an  additicnal  area  in  ECS  called  "common."  Hhereas  each 
user  has  his  own  student  variables,  there  is  only  one  copy  of 
each  cemmon,  shared  between  all  users  of  a  lesson.  A  common  may 
reside  permanently  en  disk  when  not  in  use  by  any  lesson,  being 
brought  into  ECS  by  Plato  when  needed,  and  written  to  disk  when 
no  longer  referenced;  or  it  may  be  "temporary"  common,  which  is 
net  saved  on  disk  between  sessions.  In  addition,  a  number  of 
lessens  may  share  the  same  ECS  copy  cf  a  permanent  common.  A 
common  may  new  be  up  to  8050  words  long,  and  is  ideal  for  the 
storage  of  small  to  medium  amounts  of  data,  due  to  its  low 
overhead  in  disk  accesses  and  its  easy  accessibility  in  ECS. 
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If  a  Tutor  lessen  needs  lore  storage  space,  it  can  request 
an  additional  area  of  ECS  that  will  be  individual  to  the  user. 
This  area  is  called  "storage,"  and  Bay  be  op  to  1500  words  long. 
Unlike  student  variables  cr  coamon,  Plato  does  not  save  storage 
variables  en  disk  between  sessions.  Like  student  variables, 
each  user  of  a  lesson  will  have  his  own  set  of  storage 
variables.   Storage  is  not  shared  between  users,  as  is  comon. 

All  three  of  these  memory  storage  areas,  student  variables, 
common,  and  storage,  reside  in  ECS.  1c  perform  calculations  on 
the  data  in  these  areas,  however,  they  aust  be  in  Central 
Memory.  Some  method  is  needed  for  Tutor  lessens  tc  aove  this 
data  back  and  forth  between  ECS  and  CM.  Plato  will,  at  the 
start  of  every  timeslice,  load  the  student  bank,  including  the 
student  variables,  into  a  fixed  buffer  in  CH.  The  student 
variables  may  then  be  accessed  by  the  lesson,  and  they  are 
written  back  tc  ECS  by  Plato  at  the  end  of  the  timeslice.  Since 
Plate  automatically  does  this  for  the  user,  few  people 
distinguish  between  the  ECS  copy  of  the  student  variables  and 
the  CM  copy  of  the  student  variables. 

An  area  is  also  allocated  in  CM  for  the  loading  and 
unloading  cf  common  and  storage.  The  area  where  student 
variables  are  loaded  is  called  *n*  variables,  while  the  area  for 
cemmon  and  storage  loading  is  called  *nc*  variables.  Since  *nc* 
variables  are  only  1500  words  long,  only  portions  of  coaaon  and 
storage  can  be  loaded  at  one  time.  Commands  are  provided  in 
Tutor   to   direct   Plato   to  automatically  load  and  unload  these 
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areas  of  common  and  storage  into  *nc*  variables  at  the  start  and 
end  of  every  timeslice.  It  is  up  to  the  lessen  to  decide  what 
tc  load,  and  to  see  that  the  loaded  areas  do  not  overlap. 
During  the  timeslice,  the  lesson  can  do  any  calculations  it 
wants  en  the  *nc*  variables,  and  those  *nc*  variables  that  are 
"protected"  by  being  loaded  from  ECS  will  be  saved  in  ECS  until 
the  next  timeslice.  The  *nc*  variables  that  were  not 
"protected"  will  te  zero  en  entry  tc  the  next  timeslice.  It  has 
been  possible  in  the  past  to  reference  unprotected  *nc* 
variables  during  a  timeslice,  which  provided  very  convenient 
"temporary  variables,"  whose  values  disappeared  at  the  end  of 
the  timeslice.  Ihis  is  no  longer  safe,  since  users  no  longer 
know  when  their  timeslice  will  end. 

Until  recently,  Tutor  lessons  could  not  access  disk 
directly.  Their  only  areas  of  permanent  storage  were  in  a 
user's  student  variables,  which  Plato  would  save  on  disk  when 
the  user  signed  off,  or  in  permanent  common,  which  Plato  would 
return  to  disk  when  the  last  user  left  the  last  lesson 
referencing  that  cemmen.  Direct  disk  accessing  was  provided  for 
Tutor  lessens  in  order  to  allow  users  to  store  large  amounts  of 
infrequently  accessed  data,  such  as  is  needed  in  a  filing  system 
for  student  programs. 

Disk  files  that  Tutor  lessens  may  access  are  called 
"datasets,"  and  are  organized  into  fixed  size  records  which  are 
anywhere  from  64  tc  512  words  long.  Information  read  from  disk 
may   be   sent  to  the  ECS  copies  of  student  variables,  common,  or 
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more  traditionally,  storage.  Users  of  one  lesson  may  be 
connected  to  different  datasets,  and  a  user  may  switch  froi  one 
dataset  to  another  during  execution. 

3_.6_. Besource  Limitations 

When  tfce  designers  of  the  BITS  system  first  started  on 
Plato,  the  system  was  rather  small  compared  to  its  current  size. 
At  that  time  it  had  only  a  single  CDC  6400  CPU,  only  500K  words 
of  ECS,  and  a  new  8  41  disk  system  with  three  or  four  disk  packs. 
At  present,  the  Plato  system  is  attempting  to  expand  from  two 
6400  CPUs  in  one  main  frame  to  four  CPUs  in  two  main  frames. 
Their  disk  system  is  now  both  larger  and  faster,  and  consists  of 
afcout  a  dozen  844  disk  drives.  ECS  has  been  expanded  to  the 
maximum  of  two  Billion  words.  Also  during  the  past  few  years, 
the  nunber  cf  users  on  Plato  has  increased  tremendously.  In 
cider  to  assure  a  minimum  standard  of  service  to  all  users,  the 
Plato  staff  has  placed  some  restrictions  on  all  scarce 
resources.  Naturally,  not  all  users  are  expected  to  use  all 
resources  tc  the  lisits. 

The  system  limits  en  resource  use,  particularly  on 
processing  power,  ECS  use,  and  disk  accesses,  have  been  outlined 
by  the  Plato  system  staff.  The  following  values  are  taken  from 
f Tenczar ,  1974  ],  where  the  expected  limits  for  the  following  two 
or  three  years  were  described.  Enough  processing  power  is 
available  tc  allow  twe  thousand  Central  Processor  instructions 
per   user   per   second.    ECS   space  is  available  for  about  1500 
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words  per  terminal,  and  disk  accesses  are  available  for  about 
one  access  per  user  per  ainute.  These  limits  are  what  the 
system  has  available,  but  luch  cf  each  resource  are  used  by  the 
system  in  -just  running  the  student.  The  conclusions  reached 
were  that  Plate  could  support  the  following  type  cf  operation: 
"four  terminals  sharing  a  6000  word  lesson  for  at  least  15 
minutes,  using  20CO-3000  instructions  per  terminal  per  second." 
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Chapter  H 
WITS  Design  Philosophy 

Ie  previous  chapters,  we  have  discussed  two  of  the 
influences  en  the  desiqn  of  WITS,  the  expected  users  of  WITS  and 
the  computer  system  on  which  it  would  run.  This  chapter 
discusses  our  desiqn  philosophy,  that  is,  not  what  we  did,  but 
our  attitude  as  we  did  it.  Our  first  goal  in  designing  the  WITS 
system  was  tc  provide  an  interactive  compiler  system  that  many 
people  could  use.  Our  second  goal  was  to  determine  how  far  we 
cculd  stretch  the  capabilities  of  the  Plato  system,  to  find  out 
what  it  could  really  support.  In  this  second  respect,  we  have 
been  surprised:  Plate  has  been  able  to  support  more  than  we  had 
oriqinally  expected. 

H^l_. Complete  _ System 

Since  cne  of  our  goals  was  to  serve  as  many  users  as 
possible,  we  had  to  provide  enough  features  so  that  they  would 
want  tc  use  WHS.  For  those  people  who  were  already  using  an 
established  timesharing  system,  such  as  PLOETS,  we  had  to 
provide  as  many  features  of  the  existing  system  as  possible. 
For  those  who  were  not  already  using  a  timesharing  system,  it 
was  important  that  cur  system  be  easy  to  use  even  if  one  had  no 
previous  experience.  In  discussing  a  "complete"  system,  we  mean 
a   logical   structure   of   filing   systems,   editors,  compilers. 
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interpreters,  and  debug  packages.   Each  of  these   components   is 
descrited  below. 

The  purpcse  of  an  editor  within  the  WITS  system  is  to  allow 
the  student  to  write  and  modify  a  program.  It  should  be 
organized  in  a  narner  to  make  program  preparation  a  simple,  easy 
to  understand  operation.  If  a  single  editor  is  not  suitable  for 
editing  programs  in  different  languages  simply,  multiple  editors 
are  needed,  each  one  suited  for  a  different  programming 
language.  If,  in  addition,  the  users  of  the  editors  cover  a 
wide  range  cf  sophistication  and  experience,  it  may  be  possible 
tc  provide  tore  complex,  more  powerful  editors  for  those  with 
qi°atGi  ability,  while  still  filling  the  needs  of  more 
inexperienced  users  with  the  simpler  editors. 

The  purpose  cf  a  filing  lessen  within  the  WITS  system  is, 
as  with  the  source  editors,  tc  facilitate  program  preparation. 
A  simple  filing  system  will  allow  the  user  to  save  a  program  and 
retrieve  it  later.  More  complex  filing  systems  may  allow  a  two 
level  file  structure,  manipulations  of  multiple  files,  access  of 
files  by  multiple  users,  or  any  number  of  other  options.  Two 
important  features  of  filing  systems  are  the  resources  used  for 
saving  files  and  the  stability  of  the  filing  structure  under 
adverse  conditions. 


Since  Plato  only  supports  a  single  language  for  its  users, 
for  students  to  write  programs  in  another  language  requires  the 
construction  of  a  compiler  for  that  language  and  an  interpreter 
for  the  internal  code  generated  by  that  compiler.    The   job   of 
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the  compiler  is  to  perform  syntactic  and  semantic  analysis  of 
the  user's  program  while  generating  an  easily  interpretable 
internal  fcrm  of  his  program.  An  interpreter  then  runs  over 
this  irtercal  form  executing  each  statement.  Upon  termination 
of  the  running  program,  either  normally  or  abnormally,  it  is 
possible  tc  add  a  debug  package  to  allow  the  user  to  display  the 
contents  of  any  of  his  variables. 

i*..  2. Binimal^Resource  .Use 

Since  the  Plato  system  supports  simultaneously  several 
hundred  students,  it  is  very  restricted  in  the  resources  it  can 
qive  tc  an  individual  student.  The  expected  limits  on  resource 
use  were  described  in  section  3.6.  In  order  to  assure  that  the 
WHS  system  wculd  work  once  it  had  been  implemented,  its  design 
emphasized  minimal  resource  usage.  With  this  design  we  hoped  to 
approach  as  close  as  possible  tc  these  limits,  but  we  knew  we 
could  never  reach  them.  Important  resources  we  considered 
included  disk  space,  disk  accesses,  ECS  reguirements,  and  CPU 
usaqe. 

In  designing  the  filing  lessons,  the  major  resources  under 
consideration  were  the  disk  space  reguired  to  store  many 
programs,  the  disk  accesses  reguired  to  save  or  fetch  a  program, 
and  the  ECS  needed  fcy  the  filing  lessen  and  its  directory  of  the 
disk.  These  amounts  we  used  of  each  of  these  resources  could  be 
traded  eff  to  have  an  improvement  in  cne  of  the  others.  For 
example,   keeping  the  directory  of  programs  on  disk  would  reduce 
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the  amount  of  ECS  needed,  but  would  increase  the  number  of  disk 
accesses  required  to  manipulate  programs.  Keeping  all  programs 
in  a  single  block  on  disk  would  reduce  the  number  of  disk 
accesses,  tut  would  increase  the  disk  space  needed.  Three 
important  pcints  were  considered  in  deciding  how  to  trade  off 
various  resource  uses.  First,  if  the  filing  lesson  used  too 
nuch  ECS,  at  times  it  might  net  be  accessible  to  the  student  due 
tc  a  shortace  cf  ECS,  even  if  all  the  student  wanted  was  to  save 
his  program  and  leave.  Second,  if  the  directory  for  the 
programs  was  kept  in  ECS,  it  would  be  possible  for  the  disk  to 
be  chanqed,  and  a  system  crash  tc  cause  the  changes  to  ECS 
common  tc  be  forgotten,  resulting  in  an  cut  of  date  directory. 
Third,  the  Elato  system  can  regulate  the  speed  at  which  disk 
accesses  are  dene,  but  ECS  usage  and  disk  space  usage  are 
pre-determiced  quantities.  Thus,  if  we  could  reduce  our  ECS  use 
or  disk  space  use  by  requiring  more  disk  accesses,  it  might  make 
WITS  mere  usable,  if  enly  slightly  slower. 

In  the  editors  and  compilers  in  WITS,  the  two  important 
resources  we  had  to  consider  were  ECS  reguirements  and  CPU 
usaqe.  Whenever  there  was  a  guesticn  of  whether  to  inplement 
seme  lanquage  or  compiler  feature,  the  usefulness  of  that 
feature  was  traded  off  against  the  resources  needed  by  it,  the 
work  required  to  iirplement  it,  and  the  effort  required  to 
maintain  it. 
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J4_- _3_. Language  Changes 

When  seme  language  feature  appeared  too  costly  to  be 
iaplemented  in  WITS,  we  often  felt  obligated  to  provide  some 
substitute  feature.  The  best  example  of  this  is  the  use  of 
READ-WFITE-F05M AT  statements  in  standard  Fortran.  Due  to  the 
complexity  of  these  statements,  both  in  syntax  and  semantics, 
much  ccmpiler  cede  would  have  to  be  written  to  compile  these 
statements,  and  the  CPU  time  needed  to  execute  them  would  slow 
dewn  interpretation  significantly.  The  language  features 
provided,  as  an  alternative,  were  fenat  free  PRINT  and  READ 
statements.  In  fact,  it  is  becoming  standard  to  use  format  free 
I/O  statements  in  introductory  programming  courses,  as  evidenced 
by  a  standard  Fortran  programming  textbook,  "Ten  Statement 
Fortran  Plus  Fortran  IV"  [ Kennedy , 1970  ].  Thus,  we  felt  no 
obligation  tc  stick  to  programming  language  standards  when  such 
standards  required  significantly  mere  resource  use. 

One  "justification  for  leaving  out  expensive  compiler 
features  is  the  improved  response  this  allows.  The  student 
learns  nothing  while  the  compiler  is  computing;  it  is  only  when 
the  compiler  cr  interpreter  interacts  with  the  student  that  the 
student  can  learn.  Thus,  the  faster  the  compiler  can  respond  to 
input  from  the  student,  the  faster  the  student  can  learn. 
Learning  is  especially  hindered  if  the  compiler  system  is  so 
slow  as  to  not  even  allow  the  student  to  enter  his  program  at  a 
reasonable  speed. 
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Another  justification  for  leaving  out  expensive  compiler 
features  is  the  increased  compiler  usage  this  allows.  The 
author  benefited  in  high  school  from  the  availability  of  free 
computing  time,  limited  only  by  the  availability  of  terminal 
time.  One  of  his  personal  goals  in  designing  the  HITS  system 
was  tc  provide  a  similar  system,  where  a  student  could  write  and 
run  as  many  programs  as  he  desired.  The  only  way  he  could  do 
this  was  tc  make  the  WITS  system  as  cheap  to  use  as  possible. 

4^4^ Stabl e  System 

As  authors  en  the  early  Plato  IV  system,  we  became  well 
aware  of  what  occasional  system  crashes  could  do  to  certain 
types  of  data  storage  methods  and  structures.  As  HITS 
developed,  we  endeavored  tc  design  our  data  structures  so  as  to 
be  unaffected  by  system  crashes.  Cf  course,  we  were  not  always 
entirely  successful,  but  we  did  succeed  in  making  some 
structures  less  affected  by  system  crashes.  For  example,  the 
directory  in  ECS  for  one  of  the  filing  systems  was  designed  so 
it  didn't  change  when  programs  were  saved  or  retrieved  from 
disk.  Thus,  a  system  crash  did  net  result  in  an  incorrect  file 
directory.  Another  example  would  be  that  if  a  student  enters 
WITS  with  a  program  saved  in  his  student  record,  the  automatic 
checkpointing  of  his  record  to  disk  while  he  is  running  is 
turned  off.  That  way,  if  the  system  crashes  while  he  is 
running,  his  signon  record  with  the  program  in  it  will  not  have 
been  overwritten  by  whatever  was  in  his  student  bank  while  he 
was  running. 
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Chapter  5  ' 
The  WITS  Systei  Sow 

The  first  few  chapters  of  this  thesis  described  the  users 
of  WITS  and  the  computer  system  on  which  it  runs.  The  fourth 
chapter  described  the  design  decisions  we  aade  in  building  it. 
Toqether  these  chapters  detail  why  and  how  the  WITS  systei  was 
iiplemented.  This  chapter  describes  the  resulting  systea,  its 
appearance,  its  users,  and  its  operational  characteristics. 

5.1 . Structure 

The  first  EASIC  systea  on  Plato  was  iapleaented  with  filing 
system,  editor,  ccmpiler,  and  interpreter  all  contained  in  a 
single  lesson.  In  order  to  expand  the  system  to  include  more 
compilers  we  had  to  break  it  into  connected  modules,  with  well 
defined  interfaces.  The  structure  of  Tutor  allowed  the  BASIC 
compiler/inter  prefer  to  be  placed  in  one  lesson,  accessible  from 
a  number  of  editors;  and  the  editor/filing  systea  to  be  placed 
in  another  lessen,  with  access  available  to  a  number  of 
compilers.  At  the  same  time,  work  was  in  progress  on  a  Fortran 
compiler,  and  these  changes  allowed  the  existing  editor  and 
filing  system  to  be  used  to  test  this  new  compiler. 

Currently  there  are  three  editors  available  in  the  WITS 
system.  The  first,  called  "linedit,"  is  essentially  the  saae 
editor  as  was  used  in  our  original  EASIC  systea,  though   it   has 
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been  rewritten  twice.  This  editor  is  line  oriented,  and  looks 
quite  similar  to  the  editor  that  was  available  en  the  PLOHTS 
system.  In  our  implementation,  linedit  is  quite  suited  for 
BASIC  programs,  but  may  also  be  used  for  other  languages. 

The  second  editor  built  for  the  HITS  system,  called 
"cursedit,"  is  a  cursor  oriented  editor,  quite  similar  in 
appearance  tc  those  used  in  the  CAPS  system.  All  editing 
actions  take  place  at  a  "cursor"  on  the  screen.  The  user  has 
available  function  keys  both  for  positioning  the  cursor  on  the 
screen,  and  for  performing  line,  wcrd,  or  character  operations 
on  the  text  of  his  program.  The  ability  to  specify  line  numbers 
in  cursedit  has  net  been  implemented  yet,  i.e.,  it  is  not  yet 
suitable  for  editing  EASIC  programs.  It  has,  however,  been  used 
by  CS1C5  students  fcr  running  Fortran  programs. 

The  third  editor,  called  "tutedit,"  is  currently  under 
construction.  This  editor  is  similar  in  appearance  to  the 
standard  Flatc  source  editor,  and  is  intended  for  those  users 
already  familiar  with  such  an  editor.  He  plan  for  it  to  be  able 
to  handle  programs  with  and  without  line  numbers,  so  it  may  be 
used  fcr  both  EASIC  and  other  languages. 

All  three  of  these  editors  will  use  very  much  the  same 
internal  format  for  source  programs,  in  order  to  allow  the  user 
tc  move  with  his  program  from  cne  editor  in  HITS  tc  another 
without  requiring  a  let  of  processing.  This  allows  him  to 
access  any  cf  the  compilers  in  the  HITS  system,  tc  move  to  any 
of  the  ether  editors,  and  to  use   any   filing   system   in   HITS. 
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Also,  by  standardizing  the  internal  foraat  of  user  programs,  and 
the  interface  reguireaents  between  lessons.  He  have  Hade  it  men 
easier  for  additional  lessens  to  be  added  to  the  WITS  systea. 

Two  filing  lessons  are  currently  in  use  in  the  WITS  systea. 
The  first  was  designed  in  the  fall  of  1973  along  with  the  line 
oriented  editor,  and  was  built  into  that  editor.  Each  prograa 
in  this  filing  systea  is  stored  in  a  separate  block  on  disk, 
thus  reguiring  only  a  single  disk  access  to  either  save  cr  fetch 
the  prcgraa.  The  directory  fcr  the  disk  resides  in  the  lesson*s 
common,  and  indicates  for  each  student  signon  the  block  nuabers 
that  the  student  may  save  prograas  in.  The  student  references 
these  blocks  by  way  of  letters  A,  B,  C,  through  J,  which  the 
lesson  uses  to  index  into  the  list  of  blocks  for  that  student. 
This  results  in  a  filing  system  that  reguires  very  few  disk 
accesses  and  a  small  directory  in  ECS,  and  is  very  stable  since 
the  directory  does  not  change  when  prograas  are  saved  or 
fetched.  A  large  amount  of  disk  space  is  "wasted,"  though, 
since  blocks  are  allocated  even  if  there  is  no  program  saved  in 
them,  and  because  only  one  prcgraa  is  placed  in  each  block. 


The  second  filing  lesson  in  BITS  was  designed  in  the  fall 
of  1975,  and  was  built  to  reduce  the  aaount  of  disk  space  needed 
for  saving  student  prograas.  Two  methods  Here  used  to  reduce 
this  space.  First,  prograas  were  packed  to  allow  more  than  one 
proqrat  per  disk  block,  and  second,  space  was  not  allocated  in 
the  disk  file  until  a  prograa  was  actually  to  be  saved.  This 
did   result   in   a   substantial   savings    in   disk   space. 
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Unfortunately,  it  also  resulted  in  a  very  large  directory  for 
the  disk  file  in  ECS,  and  a  directory  that  changed  when  programs 
were  saved  cr  deleted. 

Currently  accessible  from  the  editors  in  HITS  are  working 
compilers  fcr  Fortran  and  BASIC.  The  BASIC  compiler  is 
essentially  the  one  used  in  our  original  BASIC  system  cf  1973. 
The  Fortran  compiler  is  much  newer,  and  is  not  really  complete 
yet,  even  tfcouqh  it  has  enough  basic  features  and  is  reliable 
enouqh  that  it  was  used  briefly  fcr  CS105  students  in  the  fall 
of  1975.  Cf  course,  these  are  not  real  "compilers,"  they  have 
to  qenerate  an  internal  cede  for  the  user's  program  and  then 
interpret  that  internal  form.  Thus  each  of  these  compilers  is 
built  in  two  parts,  the  compiler  section  and  the  interpreter 
section,  which  could  be  in  separate  lessons,  but  are  currently 
together  in  ore  lesson. 

Two  ether  compilers  are  currently  accessible  in  the  HITS 
system,  but  only  fcr  testing  purposes.  One  is  for  an  extensible 
languaqe  called  "extran,"  and  has  been  worked  on  ty  Bruce 
Parrello.  The  other  compiler  is  beinq  constructed  by  Bruce 
Copland,  and  should  be  able  tc  execute  a  subset  of  PL/1  next 
fall. 


5,.2_. Sophistication 

There  are  several  reasons  for  makinq  the  HITS  system  fairly 
unsophisticated,  as  have  been  mentioned  in  previous  chapters. 
Our  attempt  at  unscphistication  has  been   very  successful.    He 
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provide  a  very  tasic  interactive  compiler  system  on  which 
students  can  learn  to  write  programs.  No  attempt  has  been  made 
for  oui  lessens  to  teach  the  student  how  to  program,  but  only  to 
let  him  practice  what  he  has  learned  elsewhere,  lith  this  goal, 
the  best  thing  we  can  do  to  help  him  learn  to  program  in  the 
real  wcrld  is  to  provide  a  system  where  he  can  learn  by 
practice. 

5_.J_. Speed 

He  have  been  impressed  with  the  speed  at  which  our 
compilers  and  interpreters  run;  we  would  not  have  guessed  that 
Plato  could  have  supported  such  straight  computing  as  is  done  in 
compilers  and  interpreters.  If  one  compares  the  turnaround  time 
of  many  tatch  systems  with  the  time  it  takes  to  compile  a 
proqram  in  cne  of  the  HITS  compilers,  one  finds  that  HITS  often 
takes  less  time.  This  does  not  mean  that  HITS  is  fast.  On  the 
contrary,  waitinq  at  a  terninal  while  nothing  is  happening  on 
the  screen  can  be  much  mere  aggravating  than  turning  in  a 
punched  deck  cf  cards  and  going  tc  read  a  book  while  the  job 
sits  in  the  computer.  Just  to  have  some  real  statistics,  it 
takes  approximately  100  seconds  real  time  to  compile  a  40  line 
prograii  in  the  Fcrtran  compiler  at  the  current  Plato  CPO  limit. 
Interpreting  the  internal  form  of  these  compiled  statements 
averages  1.5  tc  1.9  lines  per  real  time  second. 
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Sjji. Resource .  Use 

Pesides  CPO  use,  the  lessons  in  the  HITS  systei  use  other 
resources,  notably  ECS  space  and  disk  space.  Breaking  up  the 
WITS  systen  into  modules  contained  in  separate  lessons  has 
decreased  the  ECS  needed  tc  run  a  single  user,  since  he  is  in 
only  one  lesson  at  a  time.  For  a  whole  class  of  users,  however, 
the  ECS  use  has  only  decreased  slightly  from  our  first  BASIC 
system.  In  particular,  the  BASIC  ccmpiler  reguires  5900  words 
of  ECS,  while  the  Fortran  compiler  currently  uses  8300  words. 
The  line  criented  editor  with  the  built  in  filing  system 
requires  44CG  words  of  ECS,  while  the  cursor  editor  requires 
only  3300  wcrds.  In  addition,  each  user  in  any  cf  the  WITS 
lessens  will  have  his  own  storage  area  in  ECS,  whese  length  will 
he  anywhere  from  320  to  1C0O  words  long.  The  default  length  of 
320  words  licrks  quite  well  for  proqrams  up  to  about  60  lines 
long  using  ncne  or  a  few  small  arrays. 

Disk  space  is  used  by  the  HITS  lessons  for  permanent 
storage  of  user  prcgrams.  The  space  needed  to  stcre  each 
program  is  about  60  words  mere  than  the  length  of  the  actual 
text  in  his  program.  Most  of  these  extra  words  are  used  to  keep 
a  line  table,  describing  the  positicn  and  length  of  each  of  the 
lines  in  his  program.  The  rest  of  these  extra  words  contain  a 
header  containing  what  WITS  needs  to  know  about  the  program. 
Most  of  the  groups  using  WITS  have  allocated  enough  disk  space 
for  cne  program  per  student  tc  be  saved.  This  is  apparently 
adequate   for   most   of   their   needs,  especially  since  the  WITS 
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editors  will  cften  be  able  to  save  cne   program   in   the   user's 
student  variables  between  sessions. 

5..  5,. Stability 

As  indicated  earlier,  one  of  tee  goals  of  the  design  of  the 
WITS  system  was  that  it  be  stable,  even  under  occasional  system 
crashes.  We  are  guite  pleased  with  this  aspect  of  much  of  our 
system.  The  line  oriented  editor  and  filing  system,  as 
previously  irentioned,  does  not  reguire  changes  to  its  directory 
of  disk  when  programs  are  saved  or  deleted  from  disk.  Since  the 
directory  is  kept  in  common  for  easy  access,  this  is  very 
important,  otherwise  it  would  be  possible  for  the  directory  to 
fce  updated  in  ECS,  for  the  changes  to  be  made  on  disk,  and  then 
for  the  system  to  crash  during  the  interval  before  the  common  is 
returned  tc  disk. 

5_.6.. Mere  Work  Needed 

We  are  guite  pleased  with  the  speed  and  reliability  of  most 
of  the  WITS  system,  as  is  probably  apparent  from  the  above 
descriptions,  but  that  doesn't  mean  that  all  the  problems  in  the 
system  have  teen  solved.  In  particular,  the  stability  of  a 
filing  system  recently  added  to  WITS  is  somewhat  unknown.  In 
trying  tc  reduce  the  amount  of  -disk  space  needed  to  store 
programs,  its  directory  stored  in  common  in  ECS  reguired 
changing  when  files  were  saved  and  destroyed.  Luckily  Plato's 
reliability  has  improved  during  the  past  few  years,  but  even  so. 
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a  better  algoritha  in  that  filing  system  should  be  attempted. 


Also,  many  improvements  are  possible  in  those  parts  of  the 
system  that  are  already  being  used  by  students.  In  particular, 
a  few  extra  features  might  be  added  to  the  BASIC  compiler,  such 
as  MATBIX  statements.  The  Fortran  compiler  can  use  a  lot  of 
wcrk.  Many  useful  features  of  Fortran  have  not  been  implemented 
yet,  such  as  full  array  input/output,  or  DATA  and  COMMON 
statements.  Also,  the  errcr  diagnostics  of  both  the  Fortran 
compiler  and  the  EASIC  compiler  need  to  be  improved,  in  order  to 
help  the  student  learn  where  his  errors  are. 
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Chapter  6 
The  History  of  HITS 

As  the  reader  has  already  learned,  WITS  has  been  in  use  for 
almost  three  years  now,  in  one  form  or  another.  It  started  as  a 
EASIC  compiler,  editor,  and  filing  system  contained  in  a  single 
lesson,  capable  of  running  10  students  at  once  and  storing  maybe 
30  programs.  It  has  grown  during  that  time  tc  the  current 
system,  described  in  the  last  chapter,  which  can  support  any 
number  of  students  at  once  and  store  as  many  programs  as  the 
user  can  get  disk  space  fcr.  The  sections  of  this  chapter 
descrite  some  of  the  steps  alcng  the  way  to  the  current  WITS 
system . 

6 j. J . Changes  to  Elato  Affect  WITS 

When  we  began  to  design  WITS,  in  early  1973,  the  Plato 
system  was  still  experimental.  It  cculd  support  150  users  with 
difficulty,  crashes  could  be  expected  daily,  and  strange 
problems  with  Tutcr  lessens  could  often  be  traced  to  errors  in 
the  run-time  interpretation  routines.  Many  useful  features  of 
Tutor  were  still  tc  be  developed,  but  the  form  of  the  language, 
and  most  commands,  remain  today  as  they  were  then.  The  major 
language  changes  that  affected  the  development  of  the  WITS 
system  are  described  below.  Some  of  these  descriptions  are 
rather   technical,   and   might   only   be   understood   after  some 
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experience  en  Plate. 

fcrce  Bicrc  /  altfont  alt 

Plato  terminals  have  ever  120  built  in  characters,  with 
internal  cedes  of  six,  12,  or  even  18  bits  used  to  reference 
them.  In  crder  to  reduce  the  complexity  of  our  original  BASIC 
compiler,  we  used  six  tit  internal  codes  for  all  characters. 
This  shortened  the  amount  cf  space  needed  to  store  the  student's 
proqram,  and  mere  importantly,  it  simplified  the  implementation 
of  the  editcrs  and  compilers.  This  required  the  editor  for 
EASIC  programs  to  collect  key  presses  and  convert  them  to  the 
desired  interr.al  cedes.  This  naturally  reguired  both  Tutor  code 
and  CPU  tine. 


In  1S73,  seme  time  after  our  first  BASIC  system  was 
written,  the  Plate  system  announced  a  new  command,  -force 
micro-.  Normally  a  micro  table  is  used  to  substitute  a  series 
of  characters  for  a  single  key  press,  such  as  substituting  the 
equation  cf  an  ellipse  for  the  students  press  of  MICRO-e.  The 
-force  Bicrc-  command  directs  Plato  to  translate  all  key  presses 
throuqh  the  micro  table,  even  if  the  user  has  not  hit  MICRO. 
The  micro  table  in  the  WITS  system  translates  those  keys  in  our 
character  set  with  six  bit  internal  codes  into  themselves  (about 
50  cf  these).  These  keys  for  characters  with  12  or  18  bit  codes 
qet  translated  into  unused  six  bit  codes.  For  example,  the 
sinqle  quote  gets  mapped  into  the  code  53,  which  is  normally 
used  fcr  the  Tutor  assignment  arrow. 
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Since  it  Mould  be  a  bit  disconcerting  for  the  student  to 
see  an  assignment  arrow  when  he  typed  a  single  quote,  we  use  an 
alternate  character  set  to  change  the  display  representation  of 
our  six  tit  internal  codes.  Normally  charsets  are  used  to 
display  often  plotted  characters  or  figures  without  drawing  then 
dot  by  dot  each  time,  such  as  Russian  characters  in  a  Russian 
lanquaqe  lessen.  Charsets  are  loaded  into  the  read/write 
character  memory  of  the  terminal  ence  and  then  can  be  referenced 
as  fast  as  references  to  the  built  in,  read  only,  character  set. 
The  charset  that  SITS  uses  looks  like  the  built  in  character 
set,  except  it  is  rearranged  a  little  and  has  fewer  characters. 

Side  affects  of  having  all  input  come  through  a  micro  table 
and  all  cutput  being  shown  through  a  charset  are  nice  things 
like  havinc  Shift-o  delete  a  character  as  on  a  teletype  (the 
micro  table  translates  Shift-o  into  a  single  press  of  ERASE), 
and  displaying  capital  letters  for  lower  case  internal  codes 
(just  making  the  designs  in  the  charset  look  like  upper  case 
letters) .  It  should  be  noted  that  numbers  and  operators  in 
expressions  get  mapped  into  themselves.  This  allows  the  use  of 
standard  Plato  routines  at  execution  time  to  process  input 
expressions  and  to  display  numerical  results. 

Time  Slice  Changes 

In  early  1973,  the  programmer  of  a  Tutor  lessen  indicated, 
by  means  of  a  -break-  command,  where  Plato  should  check  to  see 
if   he   was   nearing   the   end  of  a  timeslice.   If  he  was,  Plato 
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wculd  interrupt  him  at  that  point.  When  he  returned  from  an 
interrupt,  all  his  *nc*  variables  would  be  zero,  so  before  a 
-break-,  he  wculd  generally  -unload-  his  common  and  storage  from 
*nc*  variables  into  ECS.  After  the  -break-  command,  he  would 
-load-  his  *nc*  variables  from  ECS  again.  During  a  timeslice, 
he  could  use  *nc*  variables  that  were  not  loaded  from  ECS,  and 
their  values  would  remain  intact  for  the  duration  of  the 
timeslice.  These  variables  provided  "temporary  variables," 
which  could  be  used  much  like  the  local  variables  available  in 
many  ether  programming  languages. 


In  August,  1973,  -break-  commands  became  obsolete,  with  the 
Tutor  interpreter  determining  when  a  timeslice  interrupt,  or 
-autobreak-,  should  occur.  Since  an  -autobreak-  could  happen 
between  any  twe  commands,  temporary  variables  could  now  be 
depended  cr  enly  fcr  the  duration  cf  a  single  command,  and  even 
that  iray  change  in  the  future.  Before  this  time  we  had  been 
using  temporary  variables  extensively,  so  removing  -break- 
cemmands  reguired  many  hours  cf  our  time  to  get  our  lessons 
working  again. 

The  commands  -load-  and  -unload-  were  only  usable  when  one 
knew  where  a  -break-  would  occur,  so  in  addition  to  making 
temporary  variables  obsolete,  removing  -break-  commands  also 
reguired  a  change  in  the  manner  cf  referencing  common  and 
storage.  Twc  new  commands,  -coilcad-  and  -stoload-,  were 
provided  to  automatically  load  and  unload  portions  cf  cemmon  and 
storage  every  timeslice. 
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Th€  language  resulting  after  the  implementation  of 
-autotreak-  was  cleaner  and  lore  powerful  than  the  previous 
version  of  Tutor.  However,  some  UC  hours  of  rewriting  were 
reguired  to  get  the  BASIC  filing  system,  editor,  and  compiler, 
tc  wcrk  with  -autobreak-.  Much  of  this  could  have  been  avoided 
if  we  had  known  a  year  and  a  half  ahead  of  time  what  changes 
were  planned  for  Tutor.  However,  probably  no  one  knew  at  that 
time  what  was  gcing  tc  be  done. 

6.2. Eesou ice  Shortages 

Periodically  during  the  history  of  Plato,  various  resources 

have   teen   in   short   supply   compared  to  the  demand  for  them. 

Belcw  are  descriptions  of  each  of   the  resource   shortages   the 

WITS   system  has  survived,  and  how  each  affected  the  development 
of  WITS. 

Disk  Space_Crunch 


As  with  Brany  ether  computer  systems,  Plato  has  to  be 
careful  in  allocating  its  disk  space  to  users.  At  one  time  disk 
space  was  given  to  users  freely,  but  it  was  soon  learned  that 
such  policies  wasted  disk  space.  But,  even  with  careful 
allocation,  sometines  new  disk  drives  didn't  arrive  when 
expected,  cr  the  drives  would  arrive,  at  which  point  it  was 
found  that  the  necessary  disk  controller  had  not  even  been 
ordered.  Scnetimes  Plato  was  short  of  disk  space  for  months  at 
a   time.    Cnly   rarely,   however,  did  the  HITS  project  slow  its 
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development  due  tc  the  lack  of  space  in  which  to  author  lessons, 
but  thought  was  given  continually  tc  the  amount  of  space  data 
structures  vould  take  on  disk,  and  how  many  students  could  run 
with  a  particular  disk  setup.  The  original  BASIC  system,  which 
required  a  copy  cf  the  entire  filing  system,  editor,  and 
compiler  fcr  every  grcup  of  users,  wasted  a  lot  cf  disk  space 
compared  tc  later  versions  of  HITS. 

F.CS  Crunch 

Occasionally,  during  the  three  years  that  the  author  has 
teen  running  compilers,  the  number  of  users  on  Plato  has  grcwn 
tc  where  all  the  available  ECS  has  been  in  use.  When  trying  to 
run  classes  in  instructional  lessons,  this  results  in  students 
scmetiires  being  unable  to  sign  on  to  the  system,  or  unable  to 
mcve  frcm  cne  lessen  to  another.  The  original  BASIC  system 
resided  in  a  single  lesson,  and  since  any  number  of  users  can 
share  the  ECS  copy  cf  a  lesson,  that  system  rarely  had  trouble 
running  classes.  Running  just  cne  student  during  unscheduled 
time  was  cften  impossible,  however,  since  he  was  unable  to 
obtain  a  large  amcunt  of  non-shared  ECS. 

when  WITS  was  built,  the  compilers  resided  in  lessons 
separate  frcm  the  lesson  with  the  editor  and  filing  system. 
With  this  setup,  it  was  possible  fcr  all  students  to  sit  in  the 
editor  with  the  compiler  unaccessible  due  to  lack  of  ECS.  The 
scluticn,  ence  Plato  allocated  ECS  to  physical  sites,  was  to 
reserve  a  classroom  for  a  whole  class  of  students  running  in  the 
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compiler,  and  to  ask  other  users  in  the  classioci  to  leave 
whenever  ECS  became  scarce.  Funning  a  single  student  became 
easier  with  this  setup  since  he  was  only  charged  for  the  ECS  of 
the  lessen  he  was  using  at  the  time,  either  the  compiler  or  the 
editor,  both  cf  which  were  smaller  than  the  original  BASIC 
system . 

The  current  KITS  design  assumes  classroom  use  where  both 
the  editor  and  compiler  can  be  continuously  shared  between  many 
users.  When  modifications  are  made  to  WITS,  attempts  are  made 
to  shorten  the  total  ECS  it  uses.  Also,  it  is  desireable  that 
if  the  ECS  situation  becomes  too  tight  to  run,  the  student 
should  te  atle  to  get  to  the  filing  system  and  save  his  program. 
Uses  cf  WITS  for  other  than  whole  classes  at  once  will  have  to 
be  restricted  to  ti»es  when  ECS  is  plentiful. 

CFU  Crunch 

As  the  number  of  Plato  users  has  grown,  the  CPU  time 
available  to  each  has  diminished.  To  guarantee  a  certain  amount 
cf  processing  time  for  each  user,  the  Plato  system  programmers 
have  added  software  checks  to  control  CPU  allocation.  Even  so, 
the  Plato  system  has  occasionally  felt  sluggish  to  experienced 
users.  The  worst  such  time  was  for  about  two  weeks  during  the 
1975  Spring  semester,  when  Plato  was  running  over  400  users 
regularly.  Improvements  to  the  Plato  interpreter  during  the 
following  sosirer  allowed  it  to  handle  peak  loads  of  well  over 
5C0   users   during   the   1975   Fall   semester   with   hardly   any 
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ncticable  delay.  Since  CPU  use  is  a  critical  resource,  the  WITS 
designers  have  attempted  to  keep  prccessing  tine  to  a  minimum 
without  increasing  use  of  other  resources  (such  as  ECS).  Their 
techniques  for  this  are  described  below. 

The  WI7S  system  consists  of  several  interconnected  lessons. 
Since  a  user  can  go  from  any  lessen  to  any  ether  lesson,  and 
will  cften  move  frcm  an  editor  to  a  compiler  and  back,  it  is 
important  to  keep  the  processing  tine  at  such  interfaces  small. 
This  is  dene  by  standardizing  the  internal  format  cf  the  user's 
program  in  all  the  lessons.  Additionally,  it  is  important  that 
no  compiler  destroy  information  that  an  editor  would  have  to  use 
CPU  time  tc  recompute.  At  various  times  during  the  development 
cf  WITS,  seme  lessens  violated  the  above  two  rules.  The  BASIC 
compiler  has  traditionally  destroyed  information  the  editors 
want,  just  to  save  15  words  of  ECS;  and  a  new  editor  used  a 
different  format  for  programs  in  order  to  reduce  its  own 
processing,  but  mere  processing  was  required  to  access  a 
compiler  than  was  saved.  Both  cf  these  violations  have  been 
corrected,  with  a  savings  in  processing  tiae,  and  only  a  minor 
increase  in  ECS  usage. 

The  C£PS  compiler  system  has  a  much  different  structure 
than  KITS  has.  CAPS  compilers,  rather  than  being  hard  coded 
Tutor,  are  coded  in  an  assembler-like  language,  and  are 
interpreted  by  a  common  driver,  written  in  Tutor.  Since  the 
driver  is  shared  between  all  the  compilers,  it  loses  some  of  the 
speed   it   might  have  if  it  had  language  dependent,  optimizations 


U6 


built  in.   To  save  processing  tine,  the  HITS  compilers  are  coded 
directly  in  Tutor. 

A  third  way  of  keeping  CPU  use  by  the  HITS  compilers  and 
interpreters  low  was  to  utilize  Tutor  commands  and  data 
structures  that  were  known  to  be  fast.  Such  things  included 
using  -find-  commands  where  appropriate,  referencing  full  words 
rather  than  segments  cf  words  when  possible,  and  referencing 
information  directly  rather  than  through  links  and  pointers. 

Prcbatly  the  greatest  effect  on  CPO  time  and  ECS 
consumption  was  not  from  any  cne  thing  done  during  the  design  of 
the  ccapilers,  but  rather  en  the  method  used  in  building  the 
HITS  system.  All  parts  of  the  system  were  designed  by  one  or 
mere  people  in  discussion  with  ether  authors,  but  only  one 
person  implemented  each  part.  The  system  was  thus  broken  down 
into  parts  that  cculd  be  thoroughly  understood  by  a  single 
person,  allowing  him  to  recognize  optimizations  when  he  saw 
them.  Cften,  after  a  portion  of  the  system  was  completed,  it 
was  examined  by  the  other  HITS  designer  to  make  sure  it  was 
understandable  to  both.  The  ether  designer  would  occasionally 
suqqest  improvements,  and  both  were  then  competent  to  correct 
bugs  that  appeared  in  the  lessen. 


47 


Chapter  7 


Conclusion 


Previous  chapters  have  described  who  the  WITS  compiler 
system  was  luilt  for,  how  it  was  built,  and  what  its  current 
appearance  is.  Mention  has  been  made  several  times  to  CAPS,  an 
acronym  for  the  "Computer  Assisted  Programming  System"  that  has 
been  developed  en  Plato  by  the  Computer  Science  Department  at 
the  University  cf  Illinois.  This  chapter  compares  and  contrasts 
these  two  student  compiler  systems. 

I  The  CAPS  programming  system  was  designed  to  fill  part  of 
the  role  of  a  consultant  in  helping  the  student  write  his 
program.  As  the  student  enters  his  program  in  cne  of  the  CAPS 
editors/compilers,  it  is  checked,  character  by  character  and 
token  by  token,  for  correct  syntax.  Immediately  upon  receipt  of 
an  invalid  token  or  syntactic  construct,  the  compiler  gives  an 
error  message  to  the  student,  and  the  editor  will  not  let  him 
proceed  until  he  has  corrected  his  mistake.  If  the  student  does 
net  understand  the  first  error  message,  which  generally  is  guite 
short,  he  can  press  HELP,  and  receive  a  mere  detailed 
explanation .  If  the  student  still  does  not  know  how  to  correct 
his  program,  he  can  direct  the  compiler  to  give  him  a  series  of 
changes,  each  cne  cf  which  would  make  his  program  correct 
syntactically.  The  student  can  make  cne  of  these  changes,  and 
continue  entering   his   program.    This   is   a   very   impressive 
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operation,  examples  of  which  can  be  seen  in  [ Tindall, 1975  ]. 

At  program  execution  time,  the  CAPS  interpreters  keep  trace 
information  at  every  step  of  interpretation.  If  the  student 
receives  an  execution  error  during  interpretation,  this  allows 
the  diagnostic  routines  to  actually  reverse  execute  the 
student's  program,  shewing  hi«  each  step  of  the  execution,  until 
he  can  determine  where  the  error  in  his  program  was.  This 
process  is  further  described  in  [ Davis, 1975  ]. 

In  the  area  cf  compile  time  and  execution  time  diagnostice, 
the  WHS  system  is  severely  lacking.  At  present,  the  student  is 
essentially  tcld  that  the  compiler  can  not  understand  some  line. 
A  hint  might  be  given  as  to  what  the  compiler  is  expecting  next, 
but  the  student  is  not  even  told  where  in  the  line  the  compiler 
was  processing.  Essentially,  the  student  is  expected  to  already 
know  the  syntax  for  his  programming  language,  and  the  MITS 
compilers  allow  him  to  write  programs  in  that  language.  When 
the  student  receives  a  compiler  error  message,  he  may  have  to 
look  up  in  a  reference  book  the  syntax  for  the  particular 
statement  he  wants  to  use,  and  then  follow  that  syntax  exactly. 

In  the  area  of  execution  speed  and  resource  use,  the  WITS 
system  comes  out  better  than  the  CAPS  system.  The 
editor/compiler  in  the  CAPS  system  must  be  able  to  compile 
forward  performing  syntax  checking,  and  uncompile  backward  as 
the  studert  moves  his  cursor  back  to  change  a  previous 
statement.  At  execution  time,  the  CAPS  interpreters  must  keep 
trace  information  in  order   to   allow   their   reverse   execution 
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routines  tc  wcrk.  This  naturally  requires  more  CPU  tiae  to 
collect  this  data,  and  more  ECS  space  to  keep  the  data  for  later 
use.  An  analysis  of  where  CPU  time  was  being  spent  during 
compilation  in  the  CAPS  system  was  performed  last  year,  and  is 
descrit€d  in  [ White ,1975  ]. 

In  summary,  the  Plate  system  has  two  student  compiler 
systems  currently  being  developed.  Each  system  is  designed 
differently  and  has  different  operational  characteristics.  The 
CAPS  compiler  system  is  designed  to  watch  the  student  as  he 
enters  his  programs,  and  help  him  whenever  he  has  trouble.  The 
WITS  compiler  system,  described  in  this  thesis,  is  designed  for 
speed  and  ninimum  resource  use,  in  order  that  the  student  can 
learn  programming  by  receiving  lets  of  practice.  Because  of  its 
somewhat  simpler  design,  the  HITS  system  has  been  slightly  more 
reliable  while  in  the  construction  stages,  though  this  should 
disappear  as  the  CAPS  system  is  polished  up.  Both  of  these 
systems  need  mere  wcrk,  the  CAPS  system  to  speed  it  up,  the  HITS 
system  to  improve  its  error  diagnostics. 
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